REMARKS 



In the Office Action, the Examiner rejected the claims under 35 USC §103. These 
objections and rejections are fully traversed below. Claims 1-2, 4-7, 9-23, 25-28, 30-50, 52- 
53, 55-56, 58-61, and 63-66 remain pending. 

Reconsideration of the application is respectfully requested based on the following 
remarks. 

Rejection of claims under 35 USC §103 

In the Office Action, the Examiner rejected claims 1-2, 4-5, 7, 11-14, 22-23, 25-26, 
28, 32-33, 35, 44-47, 49-50, 53, 55-56, 58, 60, 63, and 65-66 under 35 USC § 103(a) as being 
unpatentable over Wakayama et al, U.S. Publication No. US 2001/0049739 Al, 
('Wakayama' hereinafter) in view of Ishizaki, US Publication No. US 2003/0101239 Al, 
(Tshizaki' hereinafter), further in view of Frantz et al, U.S. Patent No. 5,959,990, ('Frantz' 
hereinafter), and further in view of Callon et al, U.S. Patent No. 6,643,287, ('Callon' 
hereinafter). 

Each of the pending claims recites the encapsulation of a packet or frame with a 
virtual storage area network identifier and a type of traffic. Through the identification of a 
traffic type, frames carrying a variety of traffic types may be transmitted within a VSAN. 
Moreover, multiple VSANs, each capable of supporting different traffic types, may be 
interconnected through the identification of a traffic type in the newly appended header. The 
cited references fail to disclose such a need in the prior art, or a solution such as that claimed. 

With respect to independent claim 1, as amended, recites "encapsulating the packet or 
frame with a virtual storage area network identifier, a type of traffic to be carried by the 
packet or frame, and information specifying at least one of a TTL value or MPLS 
information, wherein encapsulating comprises appending a second header to the packet or 
frame to create a new packet or frame, wherein the second header includes fields for the 
virtual storage area network identifier and information specifying at least one of the TTL 
value or the MPLS information, wherein the second header further includes a field specifying 
the type of traffic to be carried by the packet or frame, wherein the type of traffic to be carried 
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by the packet or frame is one of two or more available types of traffic, wherein the two or 
more available types of traffic include at least one of Ethernet, fibre channel, or Infiniband." 

Independent claim 55 recites in relevant part, "encapsulating the packet or frame with 
a virtual storage area network identifier and information specifying a type of traffic to be 
carried by the packet or frame, wherein the type of traffic to be carried by the packet or frame 
is one of two or more available types of traffic, wherein the two or more available types of 
traffic include at least one of Ethernet, fibre channel, or Infiniband, wherein encapsulating 
comprises adding a second header to the packet or frame to create a new packet or frame, 
wherein the second header includes fields for the virtual storage area network identifier and 
the information specifying the type of traffic to be carried by the packet or frame." 

With respect to independent claims 1 and 55, none of the cited references, separately 
or in combination, discloses or suggests "encapsulating the packet or frame with a virtual 
storage area network identifier and information specifying a type of traffic to be carried by 
the packet or frame, wherein encapsulating comprises adding a second header to the packet or 
frame to create a new packet or frame, wherein the second header includes fields for the 
virtual storage area network identifier and the information specifying the type of traffic to be 
carried by the packet or frame." In fact, none of the cited references discloses or suggests 
encapsulating the packet or frame with a VSAN identifier. Moreover, the cited references 
fail to disclose or suggest encapsulating a packet or frame with a second header including a 
field specifying the type of traffic to be carried by the packet or frame, where "the type of 
traffic is one of two or more available types of traffic, wherein the two or more available 
types of traffic include at least one of Ethernet, fibre channel, or Infiniband^" as claimed. 

A single type of traffic is typically used in a VLAN environment, as disclosed in 
Wakayama and Ishizaki. For example, the Examiner cites FIG. 9 of Wakayama, which 
discusses the configuration of the lower layer processor for the Ethernet, and discusses the 
processing of an Ethernet frame, which only includes a single header. There is no indication 
that a second header includes information specifying the type of traffic to be carried by the 
frame. In fact, FIG. 9 of Wakayama clearly indicates that only one type of traffic - Ethernet - 
is being transmitted in the VLAN described. As a result, it would be unnecessary to 
encapsulate a packet such as an Ethernet packet with an additional header to specify the type 
of traffic within that header. 

The Examiner asserts that Frantz teaches a header including a field specifying the type 
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of traffic including Ethernet type, citing FIG. 5B. FIG. 5B discloses a VTYPE field that 
identifies the frame as an extended Ethernet frame comprising a VLAN header. In other 
words, the VYPE field identifies the type of frame, but does not identify the type of traffic. 
Frantz does disclose an ETYPE field that indicates the protocol type of the next upper layer 
protocol header, which begins immediately following the ETYPE field. For example, the 
protocol type indicates the packet protocol, such as IEEE 802.3. The ETYPE field is specific 
to the data frame format for an Ethernet frame. The protocol type is not the same as a traffic 
type. In fact, Frantz clearly assumes that there is only one traffic type - Ethernet. The 
Examiner also admits that the ETYPE field is a field of an Ethernet data frame. This is 
clearly disclosed in lines 49-64 of Frantz, which discloses that this is a data frame format for 
an "Ethernet network." As a result, the traffic type (e.g., Ethernet, Fibre Channel, etc.) is not 
specified in the header of Frantz. Clearly, the system of Frantz does not disclose or suggest a 
network such as a VSAN that can support multiple traffic types. As a result, it would be 
unnecessary to append a second header including a traffic type. Accordingly, Frantz teaches 
away from identifying a traffic type in a field of a header, as claimed. 

The cited references, separately or in combination, fail to disclose or suggest 
identifying the type of traffic within a VSAN. In fact, each of the cited references relates to a 
network (e.g., VLAN or Ethernet network) in which a single type of traffic is typically used, 
and therefore teaches away from enabling multiple types of traffic to be transmitted. 
Accordingly, Applicant respectfully submits that the claims are patentable over the cited 
references. 

As set forth in the Background section of Applicant's specification, encapsulation 
mechanisms for transporting packets between ports of switches in a network on the basis of 
VLAN associations among those ports are in existence. One such encapsulation mechanism 
is ISL, developed by Cisco Systems. However, ISL does not support multiple different 
protocols on a single physical network infrastructure. Thus, current technology fails to 
address the need for supporting a multiple SAN system in which different protocols or 
technologies simultaneously co-exist. It is important to note that operating multiple different 
protocols is desirable in a SAN in order to support different storage devices operating under 
different protocols. This problem would not be immediately obvious in a VLAN 
environment in which a single type of traffic is typically supported. Moreover, ISL was not 
optimized for Fibre Channel transmissions, and therefore could not easily be implemented in 
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modern SANs. 

It is important to note that Wakayama and Ishizaki relate to a VLAN, not a VSAN. 
More particularly, Wakayama discloses providing a VLAN ID in a header of a packet. See 
Abstract. Thus, Wakayama and Ishizaki relates to a VLAN identifier rather than a VSAN 
identifier. Even though SANs are, in fact, well-known in the art, the references fail to 
disclose or suggest the claimed invention for use in a VSAN, in which multiple protocols 
may be supported. 

The claimed invention enables different types of traffic to be transmitted in a VSAN 
system. For instance, the type of MPLS information that may be specified in the header is 
recited in claims 17-20. From these claims, it can be seen that the presence and number of 
MPLS labels provided in the MPLS information can be indicated in the MPLS 
information/packet header. Thus, the MPLS information may vary, as necessary, with the 
type of traffic. In contrast, Wakayama indicates that a single MPLS label is associated with a 
VLAN ID. See Abstract. As such, Wakayama teaches away from indicating the presence 
and/or number of MPLS labels in the MPLS packet header. 

As is clear from the cited art, identifying the type of traffic in a header was previously 
not necessary, since multiple protocols could not be supported on a single physical network 
infrastructure. None of the references discloses or suggests supporting multiple different 
types of traffic on a single physical network infrastructure. Moreover, none of the references 
discloses the problem present in the current technology pertinent to the SAN environment, 
nor do they suggest a solution to this problem. Since the cited references each disclose a 
system in which a single type of traffic is used, the cited references teach away from 
supporting multiple different types of traffic in a network such as a SAN or VSAN. As such, 
the cited references teach away from appending a second header including the recited fields, 
as claimed. 

While Callon may disclose a second header, Callon fails to cure the deficiencies of 
the primary references. For example, Callon also discloses a system supporting a single 
traffic type. As a result, Applicant respectfully asserts that the combination of the cited 
references would fail to operate as claimed. Accordingly, Applicant respectfully submits that 
the pending claims 1-2, 4-5, 7-14, 22-23, 25-26, 28-35, 44-49, 53-56, 58-60, and 63-66 are 
patentable over the cited references. 
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In the Office Action, the Examiner rejected claims 6, 16-20, 27, 37-42, and 52 under 
35 USC § 103(a) as being unpatentable over Wakayama in view of Ishizaki, further in view of 
Frantz, further in view of Callon, and further in view of Behzadi, U.S. Patent No. 6,728,220 
B2, ('Behzadi' hereinafter). 

Behzadi discloses the use of a TTL field in combination with an MPLS label within a 
Shim header, as shown in FIG. 5. However, it is important to note that Behzadi relates to 
preventing transmission loops in a label switching domain. See Title. More particularly, the 
invention disclosed in Behzadi relates solely to preventing transmission loops in a ring 
network that utilizes label switching. See Abstract. Behzadi fails to disclose or suggest 
preventing transmission loops in a network that is not a ring network. As such, Behzadi 
teaches away from preventing transmission loops in a network that is not a ring network 
using a TTL field. 

It is important to note that the claimed invention relates to a SAN rather than a ring 
network. Neither of the cited references discloses or suggests the routing problems that can 
occur within a SAN. More particularly, in some SANs, there may be topology as well as 
routing problems that could cause a frame to traverse a loop within the network. As such, the 
references, separately or in combination, fail to disclose the use of the TTL field in a SAN 
environment in the manner claimed. Moreover, Behzadi fails to cure the deficiencies of the 
primary references. Accordingly, Applicant respectfully submits that claims 6, 16-20, 27, 37- 
42, and 52 are patentable over the cited art. 

The Examiner rejected claims 15 and 36 under 35 USC §103 under Wakayama in 
view of Ishizaki, further in view of Callon and further in view of Rosen et al, U.S. Patent No. 
6,337,861, ('Rosen' hereinafter), and further in view of Walrand et al, U.S. Patent No. 
6,674,760 Bl, ('Walrand' hereinafter) and rejected claims 21 and 43 under 35 USC §103 
under Wakayama in view of Ishizaki , further in view of Callon, and further in view of Rosen 
and further in view of Aggarwal et al, US 2002/0101868 Al, ('Aggarwal' hereinafter). 
These rejections are fully traversed below. 

Although the Examiner has cited Rosen in these claim rejections, it is important to 
note that Applicant was unable to find a reference or specific citation to Rosen in any of the 
claim rejections. 
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The additional references Walrand and Aggarwal fail to cure the deficiencies of the 
primary references as set forth above. Accordingly, Applicant respectfully submits that 
claims 15, 36, 21 and 43 are patentable over the cited references. 

Based on the foregoing, it is submitted that the independent claims are patentable over 
the cited references. In addition, it is submitted that the dependent claims are also patentable 
for at least the same reasons. The additional limitations recited in the independent claims or 
the dependent claims are not further-discussed as the above-discussed limitations are clearly 
sufficient to distinguish the claimed invention from the cited references. Thus, it is 
respectfully requested that the Examiner withdraw the rejection of the claims under 35 USC 
§103. 
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SUMMARY 



If there are any issues remaining which the Examiner believes could be resolved 
through either a Supplemental Response or an Examiner's Amendment, the Examiner is 
respectfully requested to contact the undersigned attorney at the telephone number listed 
below. 

Applicants hereby petition for an extension of time which may be required to 
maintain the pendency of this case, and any required fee for such extension or any further fee 
required in connection with the filing of this Amendment is to be charged to Deposit Account 
No. 504480 (Order No. ANDIP001). 



Respectfully submitted, 

WEAVER AUSTIN VILLENEUVE & SAMPSON LLP 



/Elise R. Heilbrunn/ 
Elise R. Heilbrunn 
Reg. No. 42,649 



PO Box 70250 
Oakland, CA 94612-0250 
(510) 663-1100 
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